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Priority Claim 

This application claims benefit of priority of U,S, provisional application Serial No. 
60/158,940 titled "System and Method for Enabling Single Sign-On for Networked 
Applications" filed October 12, 1999, whose inventors were Fel Bautista, Steve Lemon, and 
5 Rajeev Chawla. 

Field of the Invention 

The present invention relates to the field of networked applications, and more 
particularly to user authentication for networked apphcations. 

10 

Description of the Related Art 

Authentication and authorization are two basic computer security concepts, hi 
general, authentication refers to verifying the identity of a user attempting to gain access to 
a computing resource or system, and authorization refers to granting an authenticated user 
15 permission to access the resource or system, at least to a degree. There are many methods 
and protocols for performing authentication, each with various advantages and 
disadvantages. For example, authentication may be performed using cleartext password 
methods, hashed password methods, challenge-response methods, or any of many other 
types of methods. 

20 One common denominator of authentication methods is that they require the user to 

provide some type of information or perform some action. For example, a user may be 
required to provide a password, provide biological data such as a retinal scan, provide 
personal data such as a handwriting sample, provide a number computed based on a 
synchronized clock in the user's possession, etc. Of course, what then occurs with the 

25 provided information varies for different authentication protocols. For example, the user's 
password may be sent to the system in encrypted form, the user's password may be used as 
a variable in a mathematical function to compute a value which is then sent to the system, 
etc. 
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One major problem which users face is that as they attempt to interact with multiple 
systems or multiple resources within a system, they are often required to provide 
authentication information multiple times. This imposes practical problems to users, such 
as having to remember or store multiple passwords, having to have a synchronized clock 
5 currently in their possession, etc., as well as the frustrating workflow problems of being 
interrupted to type in a password, etc. A concept known as "single sign-on" aims to address 
these types of problems. The idea behind single sign-on is that a user is authenticated once, 
in response to providing information or performing an action as described above, and then 
finther authentication procedures are performed transparently to the user as he attempts to 
10 access other systems or resources. 

The issue of authentication may, of course, be considered at many different levels. 
For example, authentication may be considered at a system level, such as when a system 
such as a Windows NT or Unix system verifies that a user attempting to logon has a valid 
user account and has provided a valid password. Authentication may also be considered at 
15 a system resource level For example, an application which a user attempts to launch may 
authenticate the user, or an application may authenticate the user when he attempts to open 
a particular file, etc. In the case of apphcation-level authentication, the application may 
utilize a protocol or method of its own, and/or authentication data of its own, to perform the 
authentication process, or the appHcation may rely on system-level authentication services 
20 or protocols for authenticating the user. 

Most efforts to enable single sign-on have approached the problem by attempting to 
incorporate system-level authentication services or protocols into the computing 
environments in question. Kerberos is one well-known example of this type of approach. 
In the Kerberos approach, a user provides authentication information to a Kerberos server. 
25 In response, the Kerberos server grants the user a ticket-granting ticket. The user may then 
present this ticket-granting ticket to a ticket-granting server in order to get a server ticket. 
This server ticket may then be used to access resources such as apphcations. Other attempts 
to enable single sign-on by building it into the system level include IBM Corporation's 
KryptoKnight and Axent Technologies Inc.'s Enterprise Resource Manager. 
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Such approaches to single sign-on generally aim to provide a comprehensive, very 
secxxre authentication infrastructure able to provide system-wide authentication services for 
applications and other resources. While this may seem ideal, there are several 
disadvantages involved. For example, in order to introduce this type of single sign-on 
5 capability to an existing system, the system may have to be modified significantly. For 
example, the Kerberos approach may require the Kerberos server, the ticket-granting server, 
etc. to be set up. Additionally, user machines may need to be modified with special client- 
side software for the system's authentication protocol. Once the necessary modifications 
have been made to a system, there is the problem of how to define the authentication logic 
10 for the system. For example, many systems comprise multiple servers in different 
locations. System administrators must decide which of these servers the single sign-on 
poUcy appUes to, which users the policy applies to, etc. 

Assuming that the system's single sign-on policy can be adequately defined and 
supported by the authentication infrastructure, and that any necessary modifications can be 
15 made to applications and other resources in order to take advantage of the authentication 
services, the problem of system interoperabihty remains. For example, if a user of the 
system attempts to access an application on a separate system, the user may need to be 
authenticated again, even if the separate system has single sign-on capabilities of its own. 

Focusing now on networked apphcations, such as web-based applications or other 
20 Intemet or Litranet applications, the problems described above are magnified. Many 
networked apphcations require users to be authenticated, e.g. by entering a usemame and 
password on a login screen. As networked applications become increasingly 
interconnected, it becomes more desirable to enable single sign-on capabilities for them. 
For example, it may be desirable to enable a user of a web-based application to launch a 
25 second apphcation, e.g., by chcking on a hypertext link, and have the second application 
laimch immediately, bypassing an interactive authentication process that the user may 
normally have to perform when launching the second application. 

Single sign-on approaches such as the ones described above may be unsuitable for 
integrating networked apphcation authentication processes. For example, a developer of a 
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networked application may wish to enable single sign-on to a large number of other 
networked applications, each of which may run on different systems. It may be impossible 
or infeasible to make the types of modifications described above to each system. Assuming 
this obstacle can be surmounted, other obstacles may remain, such as installing any 
5 necessary client software on each user's machine, defining the access rights of users who 
connect to a system via a network connection, etc. If a networked apphcation were ported 
to a new system or a new server within a system, various steps in this process may have to 
be repeated. 

What is needed instead is a specialized application-level method enabling single 
10 sign-on integration for networked applications. Such a single sign-on method would 
preferably be managed at the apphcation level, would be independent of any particular 
computing platform or system-level authentication services, would be based on currently 
available, inexpensive technology standards in widespread use, and would require minimal 
modifications to current computer systems. 
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Summary of the Invention 

The present invention is directed toward single sign-on authentication for 
networked applications. Methods are described for enabling single sign-on both for 
applications that run in a single Internet domain and for apphcations implemented by 
5 multiple vendors which run in separate Internet domains. A system for integrating 
Internet-based applications via an application shell is described. In one embodiment, the 
application shell integrates healthcare-related apphcations. 

In response to a user utilizing a client program to access a master server and 
provide the master server with information identifying the user, the master server returns 

10 code usable by the client program for running the apphcation shell. The cHent program 
preferably comprises a web browser application or an application with web-browsing 
functionahty, and the code returned by the master server preferably comprises standard 
elements interpretable by web browsers, such as markup language code, scripting code, 
etc. The application shell may be operable to intercept user attempts to launch an 

15 application from the application shell environment and may in response determine 
invocation parameters to send to the application, which the application can use to 
automatically authenticate the user. 

In the preferred embodiment, the master server environment enables organization 
administrators to create user categories appropriate for their organizations and assign 

20 users affiliated with their organizations to these user categories. The user categories may 
correspond to job titles. For example, an administrator associated with a particular 
hospital may create user categories such as "Nurse", "Physician", etc. and may assign 
nurses, physicians, etc. associated with the hospital to their appropriate user categories. 
Organization administrators may also associate a particular set of healthcare applications 

25 with each user category, so that when each user logs on to the master server environment 
and receives the application shell code, the code is tailored to implement an application 
shell integrating an appropriate set of healthcare applications for the particular user. 

In one embodiment, in addition to enabhng single sign-on integration, the 
application shell also enables other types of application integration, such as context 
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sharing integration and user interface integration. In the preferred embodiment, Httle or 
no modification to the applications themselves is necessary in order to achieve the 
application shell integration. 

Administrators of the master server environment may provide apphcation 
administrators with an administrative tool for configuring the master server environment 
with information necessary to achieve the single sign-on integration, such as apphcation 
invocation parameters. One embodiment of an administrative tool and its interface to the 
master server environment is described below. 
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Brief Description of the Drawings 

A better understanding of the present invention can be obtained when the 
following detailed description of the preferred embodiment is considered in conjunction 
5 with the following drawings, in which: 

Figures 1 A and IB illustrate exemplary Internet-based applications; 

Figure 2 illustrates a user interacting with a web-based application via a web 
10 browser; 

Figure 3 is a block diagram illustrating one embodiment of a system for 
integrating Internet-based applications; 

15 Figure 4 illustrates a graphical user interface (GUI) for one embodiment of an 

appUcation shell; 

Figures 5-6 illustrate a graphical user interface (GUI) for one embodiment of an 
administrative tool for configuring a master server environment with user and user 
20 category information; 

Figure 7 illustrates one embodiment of a personalization GUI for users to 
personalize the set of applications integrated into their application shells; 

25 Figure 8 is a flowchart diagram illustrating one embodiment of a user accessing a 

master server environment and receiving code for an application shell; and 

Figure 9 is a flowchart diagram illustrating one embodiment of a method for 
performing single sign-on authentication for Internet-based applications. 
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While the invention is susceptible to various modifications and alternative forms 
specific embodiments are shown by way of example in the drawings and are herein 
described in detail It should be understood however, that drawings and detailed 
5 description thereto are not intended to limit the invention to the particular form disclosed. 
But on the contrary the invention is to cover all modifications, equivalents and 
altematives falling within the spirit and scope of the present invention as defined by the 
appended claims. 
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Detailed Description of the Preferred Embodiment 

Incorporation by Reference 

The following reference is hereby incorporated by reference in its entirety as 
5 though fully and completely set forth herein: 

U.S. Patent Application Serial No. titled ''System and Method for 

Application Context Sharing among Internet-Based Healthcare AppKcations," filed July 
26, 2000, whose inventors were Marco Framba, David Duncan, Venkateshwar Talla, and 
Stephen Holland. 

10 

Figure 1 - Exemplary Networked Application 

Figures lA and IB illustrate exemplary Internet-based applications. It is noted 
that Figures lA and IB represent particular embodiments of Internet-based applications, 

15 and various other embodiments are possible. 

In Figure lA, the Internet-based application is illustrated as a client/server 
application with a client side and a server side. Client process 100 communicates with a 
server process 104 via the Internet 120. The cHent process 100 and the server process 
104 may be associated with any type of application program or computing service. For 

20 example, a client process may communicate with a server process to perform a healthcare 
transaction, such as filing a health insurance claim. The server process 104 typically 
interacts with some type of server-side resource 106 on behalf of the client process. For 
example, the server process 104 may retrieve information fi:om or store information to a 
server-side database 106. 

25 The client process 100 may run in any type of client-side environment. For 

example, a client process may run in a desktop computer or workstation running any of 
various operating systems, such as Windows, Mac OS, Unix, etc., or a chent process may 
run in a portable computing device, such as a personal data assistant, smart cellular 
phone, etc. Any number of chents may communicate with the server, depending on the 
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type of application and the resources available to the server, such as network connection 
speed, processing power, etc. 

The client may use a network connection as a communication channel to send 
requests and receive responses over the Internet 120. Various types of network protocols, 
5 including TCP/IP-based protocols and UDP-based protocols, e.g. HTTP, HTTPS, etc., 
may be used to send messages across the network. As messages are sent across the 
network, the messages may pass through various gateways, network routers, etc. The 
client network connection may be a connection of any type, such as a PPP or SLIP dialup 
link, an Ethernet or token ring connection, an ISDN connection, a cable modem 
10 connection, any of various types of wireless connections, etc. 

Internet-based applications may be web-based applications or may include client- 
side web-browsing functionaUty. Figure IB illustrates one embodiment of a web-based 
application. There are, of course, many possible variations in web-based application 

15 architectures, and Figure IB is exemplary only. In general, a web-based application may 
be defined as an Internet-based application comprising a collection of resources that are 
accessible through uniform resource locators (URLs). The resources may include web 
pages comprising HTML, XML, scripting code such as Javascript or VBScript, or other 
types of elements. The resources may also include any of various types of executable 

20 programs or components, such as CGI programs, Java servlets, downloadable code such 
as Java classes or ActiveX components, etc. The resources may also include any other 
type of resource addressable through a URL. Web-based applications are often 
associated with particular communication protocols, such as HTTP or SSL. However, it 
is noted that any communication protocol may be used to access the resources. 

25 As shown in Figure IB, the client-side of the web-based application may 

comprise a web browser 132, such as the Netscape Navigator or Microsoft Internet 
Explorer apphcations. It is noted that the web-browser 132 need not be a web browser 
per se, but may be any of various types of applications that include web-browsing 
fimctionality. For example, Microsoft Corp. provides programming interfaces enabhng 
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applications to include various web-browsing capabilities provided by the Microsoft 
Internet Explorer code base. Also, as noted above, a web-based application may 
comprise code resources packaged in various forms that operate under control of the web 
browser 132, such as Java applets or ActiveX components. 

5 The web browser 132 may communicate across the Internet 120 with a web server 

136, such as an HTTP server. Depending on the application and the resource requested, 
the web server 136 may broker client application requests to server-side application code 
138 for processing, e.g., through interfaces such as CGI, ISAPI, NSAPI, etc. Server-side 
apphcation code 138 may execute on one or more separate application servers and may 

10 interface with one or more server-side databases 140. It is noted that, in other 
embodiments, the web browser 132 may interface directly with server-side application 
code 138. 



15 Figure 2 - Exemplary Application Domain 

Figure 2 is a block diagram similar to Figure 1. Figure 2 illustrates a user 152 
interacting with a web-based apphcation via a web browser 132. The server side of the 
web-based application in Figure 2 is illustrated in terms of the application's Internet 
domain 150, The embodiment of Figure 2 illustrates the application associated with a 

20 single Internet domain. However, in other embodiments, the application may run across 
multiple domains. As discussed above with reference to Figure 1, the user may provide 
URLs associated with the apphcation to the web browser 132 in order to access various 
application resources. The web browser may then interface with a web server 136. The 
web server 136 may interface with a database 140 or with other types of server resources. 

25 As discussed above, the web server 136 may interface with an application server. Also, 
the web browser 132 may interface directly with an application server, without 
interfacing with a web server. 
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Figure 3 -System Enabling Context Sharing among Internet-Based Applications 

Figure 3 is a block diagram illustrating one embodiment of a system enabling 
single sign-on authentication for Internet-based applications. Figure 3 illustrates 
exemplary apphcation domains 200A and 200B, in which web-based appUcations A and 
5 B, respectively, run. It is possible that the apphcations A and B are enabled to allow 
access by a user 202 in an independent manner, as described above with reference to 
Figure 2. The idea behind Figure 3, however, is that the user first accesses a "master web 
server" 204. In response to the user accessing the master web server, the master web 
server returns information to the user's web browser 206, where the information is usable 

10 by the web browser to implement an "application shell" 208. 

The application shell 208 provides a means for integrating independent 
apphcations into a single environment. One embodiment of an application shell and the 
integration it performs is described below. Although only two independent applications, 
applications A and B, are shown in Figure 3, the system may integrate any number of 

15 web-based applications. As described below, when the user accesses the master web 
server 204, the user may provide user information, e.g. a usemame, which the master 
server may use to identify the user and return information to the web browser for 
implementing an application shell that integrates a particular set of web-based 
applications associated with the specific user. 

20 As shown in the embodiment of Figure 3, the master server environment may 

comprise various software services, such as a login service 230, a shell service 232, and a 
personalization service 234. One embodiment of these services is described below. The 
master server environment may also comprise other types of services. The services may 
be computing services implemented using any of various technologies or programming 

25 methodologies. For example, the services may comprise CORBA services, COM/DCOM 
services, Java services, etc. 

As shown in Figure 3, organization administrators 210 associated with particular 
organizations, e.g., an administrator for a particular hospital, may utilize an 
administrative tool 212 in order to update the master server environment. The 
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administrative tool 212 may interface with the master server environment via an 
administrative interface 214 exposed by the master server environment. The 
administrative tool 212 may be provided to organization administrators 210 by master 
server administrators. One embodiment of an administrative tool 212 and its interface to 
5 the master server environment are described below. Exemplary types of information 
which may be set via the administrative tool 212 are also described below. In particular, 
organization administrators 210 may create user categories, assign users affiliated with 
their organizations to these user categories, and associate a particular set of web-based 
applications with each user category. 

10 Figure 3 also illustrates means for performing other aspects of administration of 

the master server environment. As shown in Figure 3, application administrators 220 of 
particular healthcare applications, e.g., an administrator for an apphcation associated with 
performing laboratory tests, may utiHze an administrative tool 218 in order to update the 
master server environment. Application administrators 220 may utilize the administrative 

15 tool 218 in order to specify integration information, such as single sign-on invocation 
parameters, for their particular applications. The administrative tool 218 may be 
provided to apphcation administrators 220 by master server administrators and may 
interface with the master server environment via an administrative interface 214 exposed 
by the master server environment. 

20 It is noted that, in some cases, a single administrator may perform both 

apphcation administration and organization administration tasks. For example, an 
administrator associated with a particular hospital may be in charge of both maintaining 
user information for system users associated with the hospital, and maintaining 
application information, e.g., for an intra-hospital laboratory test apphcation. Also, the 

25 functionality of administrative tools 212 and 218 may be incorporated into a single 
administrative tool 

The system illustrated in Figure 3 may provide a means for linking various 
healthcare apphcations, such as apphcations for laboratory test administration, health 
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insurance claim administration, hospital patient administration, etc. However, although 
the system is described in terms of the healthcare industry and healthcare applications, it 
is noted that the system may be used for integrating many other types of applications. 



5 

Figure 4 - Application Shell User Interface 

Figure 4 illustrates an exemplary graphical user interface (GUI) for one 
embodiment of an application shell The application shell preferably runs within a web 
browser application, based on code, such as markup language code and scripting code, 

10 received from a master server, as described below. 

Figure 4 shows a navigation bar 300 along the left side of the screen. The 
navigation bar comprises hypertext links associated with various Internet-based 
healthcare applications. For example, the Figure 4 apphcations include applications 
associated with health insurance administration, applications for viewing clinical reports, 

15 applications associated with prescription administration, etc. As shown in Figure 4, the 
navigation bar may include selectable tabs 302 for logically grouping the set of 
applications that the application shell integrates. As described in detail below, the master 
server may provide speciahzed code to the web browser, enabling the web browser to 
implement an application shell tailored to the particular user or to a user category that the 

20 particular user belongs to. For example Figure 4 illustrates an application shell GUI that 
integrates a typical set of healthcare apphcations that may be used by a nurse employed in 
a physicians' office. For other types of users, such as health insurance administrators, the 
delivered set of healthcare applications may differ. 

The set of apphcations accessible via the navigation bar may include disparate 

25 types of healthcare-related applications, and these applications may be provided by 
multiple vendors and may run across multiple Internet domains. The application shell 
provides a means for integrating the set of applications, including single sign-on 
integration. The application shell may also provide a means for other types of application 
integration, as discussed below. 
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Figures 5 - 6 : User Administration 

Figures 5-6 illustrate a graphical user interface (GUI) for one embodiment of an 
5 administrative tool for configuring the master server environment for delivering 
appUcation shell information to users. As discussed above with reference to Figure 3, an 
administrative tool for configuring the master server environment may be provided to 
organization administrators by master server administrators. 

Figure 5 illustrates one embodiment of a GUI for creating a user category, e.g. a 

10 job description, and associating a particular set of healthcare applications with the user 
category. Advantageously, each organization administrator may associate applications 
with user categories as appropriate for his particular organization. For example, many 
separate healthcare organizations may employ users with a job title of "nurse". However, 
the role of a nurse may differ significantly across different organizations. Thus, it is 

15 desirable for each organization administrator to be able to create a "nurse" user category 
for nurses in his particular organization and to assign the appropriate set of healthcare 
applications to the nurse user category. 

Figure 6 illustrates one embodiment of a GUI for adding a new user. As shown, 
20 the GUI may include fields for specifying personal information, such as the user's name, 
email address, etc. A usemame may be assigned to uniquely identify the user. The GUI 
preferably also includes a field for choosing a user category for the user. In the Figure 6 
example, the "Job" field is used to assign the user to a user category. 

25 

Application Administration 

As discussed above, administrators of the master server may provide application 
administrators with an administrative tool for configuring the master server environment 
with application information. This section a graphical user interface (GUI) for one 

Atty. Dkt. No.: 5435-07101 Page 15 Conley, Rose & Tayon, P.C. 



embodiment of an administrative tool for performing this configuration. The 
administrative tool GUI may comprise a name field for specifying a name for the 
application. The name specified may appear in the user's application shell GUI on the 
navigation bar. For example, one of the apphcation names in the Figure 4 application 
5 shell GUI is "Clinical Reports". The administrative tool GUI may also comprise a field 
for specifying a location of an icon associated with the apphcation that should be 
displayed in the application shell GUI. 

The administrative tool GUI may also comprise fields for specifying where the 
application name should appear in the application shell GUI. For example, in one 

10 embodiment, the application shell GUI comprises a navigation bar, as described above, 
and a toolbar, which may appear above the main window or fi-ame. The administrator 
may specify whether the apphcation name should appear on the navigation bar or the 
toolbar. Applications appearing on the navigation bar may be grouped into sets of related 
applications. For example, the Figure 4 navigation bar shows "Financial", "Clinical", 

15 and "Admin" groups. The administrative tool GUI may comprise fields for selecting the 
appropriate group for the apphcation, or adding or deleting groups. 

The administrative tool GUI may also comprise a URL field for specifying a 
uniform resource locator (URL) for launching the application. Applications to be 
integrated into an application shell may be provided by various vendors and may run in 

20 any location accessible via a URL. 

The administrative tool GUI may also comprise fields for specifying windowing 
behavior in the application shell GUI. For example, the GUI may comprise a window 
field for specifying whether the application should be launched in a separate window 
when it is invoked by a user, or whether it should replace the main application shell GUI 

25 window or frame. 

The administrative tool GUI may also comprise various fields for specifying 
options related to application single sign-on integration or other types of application 
integration, such as context sharing integration. For example, an invocation parameters 
field may be used to specify values to pass to the application when the application is 
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invoked. An invocation type field may be used to specify the method for invoking the 
appUcation and passing invocation parameters, e.g., via an HTTP GET or an HTTP POST 
operation, etc. Encryption fields may specify whether information passed to the 
application should be encrypted, and which encryption method to use. Invocation 

5 parameters are discussed in more detail below. 

As described below, users may personalize their appHcation shell GUI by 
specifying the applications they want to appear on the GUI. The administrative tool GUI 
may comprise an allow suppression field for specifying whether users are allowed to 
suppress the appearance of the application name. 

10 The administrative tool is described above in terms of its use by administrators 

associated with particular applications. However, administrators of the master server 
environment may also, of course, utihze such an administration tool for configuring 
application information. Also, as previously noted, an administrator may perform both 
organization administration and application administration functions. 

15 



Figure 7 - User Personalization 

As discussed above, organization administrators may create user categories, 
associate a set of applications with the user categories, and assign members of their 

20 organizations to the user categories. Means for users to further refine the set of 
appUcations dehvered to their application shells may also be included. In the preferred 
embodiment, this means comprises a personalization GUI accessible via the application 
shell GUI. For example, Figure 4 shows a "Personalization" hypertext hnk on the 
application shell GUI navigation bar. Figure 7 illustrates one embodiment of a 

25 personaHzation GUI. As shown, the personalization GUI may comprise a field for 
specifying a particular application group. Once the group has been selected, a list of 
applications associated with the group may be displayed, and the user may select which 
apphcations he wants to appear in the apphcation shell GUI. As noted above, some 
applications may be configured to be insuppressible. 
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As described below, the master server may access the user's personalization 
information set via the Figure 7 GUI when the master server returns the apphcation shell 
information to the user's web browser, 

5 

Figure 8 - Returning Apphcation Shell Information to Web Browser 

Figure 8 is a flowchart diagram illustrating one embodiment of a user accessing 
the master server environment and receiving code for an application shell. 

In step 250 of Figure 8, a user provides a URL associated with the master server 

10 environment to a web browser, and the web browser estabUshes communication with the 
master server, e.g., by interfacing with a login service. For example, the URL may 
reference a master server login web page. In step 252 of Figure 8, the master server login 
service requests information identifying the user. For example, the login service may 
request a usemame, an email address, or other information that may be used in 

15 identifying the user. In step 254 of Figure 8, the web browser presents a graphical user 
interface (GUI) for the user to provide the identifying information to the master server. 
Steps 252 and 254 may be accompUshed in various ways, e.g., by the login service using 
standard methods causing the web browser to present a login dialog box to the user, or by 
the login service returning an HTML login form which the web browser then displays, 

20 etc. In step 256 the web browser transmits the identifying information provided by the 
user to the master server login service. 

In step 258 of Figure 8, the master server login service receives the identifying 
information from the web browser. The login service passes the identifying information 
to a shell service running in the master server environment and requests the shell service 

25 to return code to the web browser for running an appropriate application shell for the 
user. The login service may, of course, authenticate the user or interface with an 
authentication service before contacting the shell service. 

In step 260 of Figure 8, the shell service passes the identifying information to a 
personahzation service running in the master server environment and requests the 
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personalization service to return a set of applications, e.g. a list of application URLs, 
associated with the user. 

As discussed above, an organization administrator for the user's organization, 
e.g., a computer administrator for the user's employer, may create user categories, e.g., 
5 categories based on particular job titles used in the organization, and may associate a 
particular set of applications with the user categories, and may assign each user affiliated 
with the organization to a user category. In step 262 of Figure 8, the personalization 
service uses the identifying information received from the shell service to determine the 
user category that the user is assigned to, e.g., by accessing a database that stores this 
10 information. The personalization service also determines the set of applications 
associated with the user's user category, e.g., by accessing a database that stores this 
information. 

As discussed above, a user may have previously utilized a personahzation GUI 
associated with the master server environment, in order to specify particular applications 

15 from the set of applications associated with the user's user category that the user does not 
want to be integrated into the user's apphcation shell GUI. In step 264 of Figure 8, the 
personalization service may access this personalization information for the user, e.g., by 
accessing a database that stores this information, in order to determine a subset of the set 
of applications that should be returned to the shell service. 

20 In step 266 of Figure 8, the personalization service returns the subset of 

applications to the shell service, e.g. by returning a list of URLs associated with each 
application, or by returning keys that the shell service may use to identify the 
applications. 

In step 268 of Figure 8, the shell service transmits apphcation shell code to the 
25 web browser, where the application shell code comprises information usable by the web 
browser for displaying a GUI enabling the user to invoke the applications returned by the 
personalization service. In one embodiment, the application shell code comprises 
standard elements interpretable by web browser applications, such as markup language 
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code, e.g., HTML code or code for XML-derived markup languages, along with other 
standard elements, such as scripting code, e.g. Javascript, VBScript, etc. 

In step 270 of Figure 8, the web browser parses the application shell code from 
the shell service and runs the application shell, preferably using common web browser 
5 standards. 



Figure 9 - Single Sign-On Method for Networked Apphcations 

Figure 9 is a flowchart diagram illustrating a single sign-on method for networked 

10 applications. For the sake of clarity, the "first" networked apphcation which the user 
interacts with in order to authenticate himself is referred to as the primary application. 
Any applications which the user then launches from the environment of the primary 
application, and which the user is transparently authenticated against, are referred to as 
secondary apphcations. In one embodiment, the primary application may be an 

15 apphcation shell such as described above. It is noted, however, that the method shown in 
Figure 9 may also be apphed for various other types of systems and apphcations. 

In step 200, the user is authenticated to a primary apphcation. For example, when 
the user tries to access the primary apphcation, the apphcation may initiate a login 
process requiring the user to provide information such as a password, or biological or 

20 other personal information, etc. After providing this information, the chent side and the 
server side of the primary apphcation may perform an authentication process using any of 
various authentication methods, such as cleartext methods, hashed password methods, 
challenge-response methods, etc. Upon successfiil completion of this authentication 
procedure, the chent side may receive some type of token from the server side, indicating 

25 that the user has been authenticated and authorized to use the primary application. For 
example, for a web-based primary application, this token may be a cookie sent to the 
client side. 

In step 202, the user attempts to launch a secondary apphcation from the 
environment of the primary application. The user may attempt to launch the secondary 
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application using any method supported by the primary apphcation. For example, the 
user may attempt to launch a secondary application in a web browser window or frame, 
e.g., by clicking on a hypertext link displayed by the primary application or executing a 
menu command in the primary apphcation, etc., or the user may attempt to launch a 

5 secondary apphcation running in a customized window, e.g., by executing a menu 
command in the primary application or by operating an ActiveX control from a browser 
window displaying the primary application, etc. As noted, in one embodiment, the 
primary application may be an application shell, and the secondary application shell may 
be an application that the application shell integrates with other apphcations via its 

1 0 graphical user interface. 

In step 204, the primary apphcation intercepts the user's request to launch the 
secondary apphcation. The primary application may intercept this request in various 
ways, as appropriate to the application environment. For example, the primary 
apphcation may register an event handler, such as a Javascript OnClick event handler, to 

15 catch a click on a hypertext link associated with the secondary apphcation, or the primary 
application may register a menu item event handler to catch a menu command to launch 
the secondary application, etc. 

In step 206, the client side of the primary apphcation requests appropriate 
authentication parameters for the user from the server side of the primary apphcation. 

20 This request may be sent using any of various protocols, such as HTTP, SSL, other 
TCP/EP-based protocols, etc. 

In step 208, the server side of the primary application generates appropriate 
authentication parameters which can be used to authenticate the user to the secondary 
apphcation. For each user, the server side of the primary application preferably maintains 

25 persistent information, e.g., information stored in a database, which can be used to 
determine the appropriate authentication parameters to use for each of the various 
secondary applications that the user may launch from the primary application. This 
information may be set in various ways. For example, the information may be set 
programmatically as part of a user registration process, or the information may be set 
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interactively through an administrative tool One embodiment of an administrative tool 
that allows administrators of secondary applications to set up the appropriate 
authentication parameter information for each secondary application user is described 
below. The authentication parameter information may be stored in an encrypted form. 

5 The nature of the stored authentication parameter information may vary. For 

example, the information may comprise a string, numerical data, or any other type of 
data. What is important is that the stored authentication parameter information can be 
used to generate valid authentication parameters that the secondary apphcation accepts as 
valid authentication information for the user. In the preferred embodiment, these 

10 authentication parameters are generated by applying a cryptographic technique to the 
stored authentication parameter information. Any of various cryptographic techniques 
may be applied, including symmetric encryption algorithms, such as DES or Triple-DES, 
asymmetric encryption algorithms, such as the RSA system, etc. The primary application 
preferably supports multiple cryptographic techniques and allows administrators of 

15 secondary applications to select which technique(s), if any, to use in generating the 
authentication parameters. For example, secondary administrators may select which 
technique to use via an administrative tool GUI. 

The authentication parameters generated by the server side of the primary 
application may also include other information besides the authentication parameters 

20 described above. For example, the authentication parameters may include a montonically 
increasing sequence number. Such a sequence number may be used, for example, if the 
chent side of the primary apphcation keeps a history hst, such as the history hst kept by 
many web browsers. As described below, the sequence number may be checked by the 
secondary apphcation in order to prevent the user from accessing the secondary 

25 apphcation again using the history list. The generated authentication parameters may 
also include an expiry time for the authentication parameters, or any other desired or 
necessary information. 

Once the authentication parameters for the user have been generated, the server 
side of the primary apphcation returns them to the client side of the primary application 
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in step 210. The parameters may be returned using any of various protocols, such as 
HTTP, SSL, other TCP/IP-based protocols, etc. 

In step 212, the client side of the primary application uses the authentication 
parameters to invoke the secondary application. The secondary application may be 

5 invoked in various ways, as appropriate for the environment of the primary application, 
and as supported by the secondary application. The primary application preferably 
mvokes the secondary appUcation by contacting the server side of the secondary 
appUcation, passing along the user's authentication parameters. For example, in step 202, 
if the user requested that the secondary application be launched by clicking on a hypertext 

10 link, then, as described above, an event handler, such as a Javascript event handler may 
catch the request and contact the server side of the primary application to obtain the 
appropriate authentication parameters. In this example, the event handler may then 
invoke the secondary apphcation by invoking a URL associated with the link the user 
clicked on. The authentication parameters may be provided along with the URL, e.g. by 

15 appending them as a query string to the URL and performing an HTTP GET operation, or 
by placing them in an HTML form and performing an HTTP POST operation, etc. For 
other types of primary or secondary appUcations, the invocation may occur in other ways. 
For example, the primary appUcation may contact a client-side program associated with 
the secondary apphcation, passing the client side of the secondary application the 

20 authentication parameters, e.g., as command line arguments. The client-side of the 
secondary application may then be operable to contact the server side of the secondary 
application, in order to begin the authentication process for the secondary apphcation. 

In step 214, the server side of the secondary application uses the authentication 
parameters received in step 212 to attempt to authenticate the user. The secondary 

25 application should be configured to use the appropriate techniques for properly decoding 
the authentication parameters, if any cryptographic techniques were applied in step 208. 
The secondary apphcation may perform additional operations or checks on the 
authentication parameters. For example, if the authentication parameters include an 
expiry tune, the secondary application may ensure that the parameters are still vahd. If 
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the authentication parameters include a monotonically increasing sequence number, the 
secondary apphcation may enforce this sequence number. 

Once the authentication parameters have been decoded and possibly checked for a 
valid expiry time, sequence number, etc., the secondary application may use them to 

5 attempt to authenticate the user. As described above, the nature of the authentication 
parameter information stored by the server side of the primary application may vary, 
possibly comprising data of any kind. The nature of the authentication parameters 
received by the server side of the secondary apphcation may thus vary also. The 
secondary application may thus perform any type of operation or processing on the 

10 authentication parameters that is necessary to authenticate the user. 

Assuming that the secondary application was able to successfully authenticate the 
user in step 214, the secondary apphcation is launched in step 216. The actions involved 
in launching the secondary application may vary for different types of primary and 
secondary applications. For example, if the secondary application uses web pages, then 

15 the server side of the secondary apphcation may return an initial web page for the 
secondary application. This initial web page may then be displayed in a frame, such as an 
HTML frame, alongside frames associated with the primary apphcation, or may be 
displayed in a separate window. If necessary, a client-side program, such as a web 
browser program, may be invoked in order to display a web page for the secondary 

20 apphcation. For other types of secondary applications, other types of client-side 
programs associated with the secondary application may be launched. For example, if the 
secondary application is a game application requiring a special chent-side program, then 
this client-side program may launch. 

If the secondary apphcation cannot authenticate the user in step 214, then the 

25 secondary application may notify the user with an error message. The secondary 
apphcation may also present an exphcit authentication mechanism, such as a login screen, 
to the user. The secondary application may also alert the administrators of the secondary 
application that the single sign-on failed for the user, e.g. by sending an email message. 
A secondary application administrator may then update the information stored on the 
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server side of the primary application so that future single sign-on attempts by the user 
will succeed. 

5 Context Sharing Integration 

As noted above, in one embodiment the application shell may also be operable to 
enable application context sharing for the apphcations integrated by the application shell. 
Application context sharing refers to the transparent sharing of application context as a user 
switches between apphcations. For example, a physician may be interacting with a patient 

10 administration apphcation, viewing information about a patient named "John Doe". The 
physician may then desire to sv^tch to another apphcation. For example, the physician may 
want to switch to an apphcation allowing him to see laboratory test results for John Doe, 
Normally, this would require the physician to manually set the apphcation context in the 
second apphcation, e.g., by performing a search operation for "John Doe". The idea behind 

15 apphcation context sharing, however, is that the apphcation context for the second 
application is set automatically in response to the user invoking the second apphcation. In 
this case, for example, the laboratory test apphcation may automatically show the physician 
John Doe's laboratory records. For example, the application shell may be operable to pass 
context sharing invocation parameters to the apphcations, similarly as described above 

20 for passing context parameters. One embodiment of a system and method for enabling 
this context sharing capability is described in the above-incorporated U.S. patent 
application titled, "System and Method for Application Context Sharing among Internet- 
Based Healthcare Apphcations". 

25 Although the system and method of the present invention has been described in 

connection with the preferred embodiment, it is not intended to be limited to the specific 
form set forth herein, but on the contrary, it is intended to cover such alternatives, 
modifications, and equivalents, as can be reasonably included within the spirit and scope 
of the invention as defined by the appended claims. 
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Claims 

We claim: 

5 LA method for automatically authenticating a user of a first networked 

application to a second networked appUcation, the method comprising: 

the first networked apphcation receiving authentication information from the user; 
the first networked application authenticating the user to use the first networked 
application in response to said receiving the authentication information from the user; 
10 launching the second networked apphcation, wherein said launching comprises 

the first networked apphcation providing authentication information associated with the 
user to the second networked application; 

the second networked application authenticating the user to use the second 
networked apphcation in response to receiving said authentication information from the 
15 first networked application. 

2. The method of claim 1, wherein said launching the second networked 
apphcation comprises the user performing an action which triggers a programmatic event, 
the method further comprising: 
20 the first networked application intercepting the event; 

the first networked application providing authentication information associated 
with the user to the second networked application, in response to said furst networked 
application intercepting the event. 

25 3 . The method of claim 2, 

wherein said launching the second networked apphcation comprises the user 
clicking on a hypertext link associated with the second application; 

wherein said user clicking on the hypertext link triggers a programmatic event 
representing the click; 
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wherein the first networked application includes an event handler which intercepts 
the click event. 

4. The method of claim 3 , 

5 wherein the event handler is a Javascript event handler. 

5. The method of claim 1 

wherein said first networked application providing authentication information 
associated with the user to the second networked appUcation comprises: 
10 the client side of the first networked appHcation requesting and receiving 

authentication parameters from the server side of the first networked appUcation, wherein 
the authentication parameters comprise information for authenticating the user to the 
second networked appHcation; 

the client side of the first networked application providing the 
15 authentication parameters to the server side of the second networked application. 

6. The method of claim 5, 

wherein said launching the second networked application comprises the user 
clicking on a hypertext link associated with the second application; 
20 wherein the first application includes an event handler that intercepts an event 

triggered by the user cUcking on the hypertext link; 

wherein the event handler requests and receives authentication parameters fi-om 
the server side of the first appUcation, wherein the authentication parameters comprise 
information for authenticating the user to the second networked appUcation; 
25 wherein the event handler passes the authentication parameters to the server side 

of the second networked appUcation. 

7. The method of claim 6, 
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wherein said event handler passing the authentication parameters to the server 
side of the second networked appUcation comprises the event handler appending the 
authentication parameters onto a URL associated with the second networked appUcation; 

wherein the event handler performs an HTTP GET request using the resulting 

5 URL. 

8. The method of claim 6, 

wherein said event handler passing the authentication parameters to the server 
side of the second networked application comprises the event handler performing an 
10 HTTP POST request using a URL associated with the second application; 

wherein the authentication parameters are sent to the server side of the second 
networked application as posted data, 

9. The method of claim 5, 

15 wherein the server side of the first networked appUcation stores information 

associated with the user in a database; 

wherein the stored user information is used to generate the authentication 

parameters. 

20 10. The method of claim 9, wherein the user information stored by the server 

side of the first networked appUcation was previously set by an administrator of the 
second networked application using an administrative tool. 

1 1 . The method of claim 5 , 

25 wherein the authentication parameters received from the server side of the first 

networked application are encrypted. 

12. The method of claim 1 1 , 
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wherein the server side of the first networked apphcation is enabled to apply 
various cryptographic techniques to the authentication parameters; 

wherein an administrator may specify which techniques to apply using an 
administrative tooL 

5 

13. The method of claim 1 1 , 

wherein the authentication parameters include a sequence number. 

14. The method of claim 1 1 , 

10 wherein the authentication parameters include an expiry time, 

16. The method of claim 1 , further comprising: 

the second networked application launching after said second networked 
application authenticating the user to use the second networked application. 

15 

17. The method of claim 16, 

wherein the second networked apphcation is a web apphcation; 
wherein said second networked application launching comprises the server side of 
the second networked apphcation returning an initial web page to the client side of the 
20 second networked application. 

18. A system for performing single sign-on user authentication, the system 
comprising: 

a first computer system running chent-side software associated with a first 
25 networked application; 

a second computer system connected to the first computer system via a network, 
wherein server-side software associated with the first networked apphcation runs on the 
second computer system; 
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a third computer system connected to the first computer system via a network, 
wherein server-side software associated with a second networked appUcation runs on the 
third computer system; 

wherein the chent-side software associated with the first networked apphcation is 
5 operable to: 

receive authentication information from a user; 

communicate with the server-side software associated with the first 
networked appUcation in order to authenticate the user to use the first networked 
appUcation, in response to said receiving the authentication information from the user; 

10 launch the second networked application, wherein said launching 

comprises providing authentication information associated with the user to the server-side 
software associated with the second networked application; 

wherein the server-side software associated with the second networked application 
is operable to authenticate the user to use the second networked application, in response 

15 to receiving said authentication information from the client-side software associated with 
the first networked appUcation. 



19. The system of claim 18, 

wherein said launching the second networked application is performed in response 
20 to intercepting a programmatic event triggered by the user requesting to launch the 
second networked application, 

20. The system of claim 1 8, 

wherein said launching the second networked application is performed in response 
25 to intercepting a programmatic event triggered by the user cUcking on a hypertext link 
associated with the second application; 

wherein the cUent-side software associated with the first networked application 
includes an event handler which intercepts the click event. 
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21 . The system of claim 20, 

wherein the event handler is a Javascript event handler. 

22. The system of claim 1 8, 

5 wherein said providing authentication information associated with the user to the 

server-side software associated with the second networked application comprises: 

requesting and receiving authentication parameters from the server-side 
software associated with the first networked appUcation, wherein the authentication 
parameters comprise information for authenticating the user to the second networked 

10 apphcation; 

providing the authentication parameters to the server-side software 
associated with the second networked apphcation. 

23. The system of claim 22, 

15 wherein said launching the second networked application is performed in response 

to the user clicking on a hypertext link associated with the second application; 

wherein the client-side software associated with the first networked apphcation 
includes an event handler that intercepts an event triggered by the user clicking on the 
hypertext link; 

20 wherein the event handler requests and receives authentication parameters from 

the server-side software associated with the first networked apphcation, wherein the 
authentication parameters comprise information for authenticating the user to the second 
networked apphcation; 

wherein the event handler passes the authentication parameters to the server-side 

25 software associated with the second networked application. 

24. The system of claim 23, 

wherein said event handler passing the authentication parameters to the server- 
side software associated with the second networked apphcation comprises the event 
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handler appending the authentication parameters onto a URL associated with the second 
networked appUcation; 

wherein the event handler performs an HTTP GET request using the resulting 

URL, 

5 

25. The system of claim 23, 

wherein said event handler passing the authentication parameters to the server- 
side software associated with the second networked application comprises the event 
handler performing an HTTP POST request using a URL associated with the second 
10 networked application; 

wherein the authentication parameters are sent to the server-side software 
associated with the second networked application as posted data. 



26. The system of claim 22, 
15 wherein the server-side software associated with the first networked application 

stores information associated with the user in a database; 

wherein the stored user information is used to generate the authentication 
parameters. 

20 27. The system of claim 26, wherein the user information stored by the server- 

side software associated with the first networked application was previously set by an 
administrator of the second networked application using an administrative tool. 



28. The system of claim 22, 
25 wherein the authentication parameters received fi-om the server-side software 

associated with the first networked application are encrypted. 



29. The system of claim 28, 



Atty. Dkt. No.: 5435-07101 



Page 32 



Conley, Rose & Tayon, P.C. 



wherein the server-side software associated with the first networked apphcation is 
enabled to apply various cryptographic techniques to the authentication parameters; 

wherein an administrator may specify which techniques to apply using an 
administrative tool. 

30. The system of claim 1 8, 

wherein the cHent-side software associated with the first networked apphcation 
comprises an application including web-browsing functionality. 
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Abstract 

A system and method for performing single sign-on authentication for networked 
appHcations. A system for integrating networked apphcations via an appUcation shell is 
described. In response to a user utihzing a chent program to access a master server and 
5 provide the master server with information identifying the user, the master server returns 
code usable by the client program for running the application shell. The application shell 
may be operable to intercept user attempts to launch an application from the appUcation 
shell environment and may in response determine invocation parameters to send to the 
application, which the application can use to automatically authenticate the user. 
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user provides login URL to web browser 
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web browser presents a GUI for the user to provide 
the identifying information 
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web browser transmits the identifying infonnation to 
the master server 
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master server passes the identifying infonnation to 
a shell service and requests the shell service to 
return code to the web browser for running an 
application shell 
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shell service passes the identifying information to a 
personalization service and requests a set of 
Internet applications associated with the user 
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personalization service accesses a database to 
determine the user's user category and to 
determine the set of Internet applications 
associated with the user's user category 
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personalization service accesses a database to 
determine a subset of the set of Internet 
applications to return to the shell service 
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personalization service returns the subset 
of Internet applications to the shell service 
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shell service transmits application shell 
code to the web browser, where the code 
comprises information usable for invoking 
the subset of Internet applications 
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web browser parses the code received from 
the shell service and runs the application 
shell 
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application 
210 



primary application invokes 
secondary application, passing 
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212 



secondary application uses 
authentication parameters to 
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DECLARATION 

As a below named inventor, I hereby declare that: 

My residence, post office address, and citizenship are as stated below next to my name. 

I believe I am the original, first and sole inventor (if only one name is listed below) or an original, first and 
joint inventor (if plural names are Hsted below) of the subject matter which is claimed and for which a patent is 
sought on the invention entitled "SYSTEM AND METHOD FOR ENABLING SINGLE SIGN-ON 
FOR NETWORKED APPLICATIONS," the specification of which: 

^ is attached hereto. 

Q was filed on as Application Serial No. 

and was amended on (if applicable). 

I hereby state that I have reviewed and understand the contents of the above-identified specification, 
including the claims, as amended by any amendment referred to above. 

I acknowledge the duty to disclose to the Patent and Trademark Office all information known to me to be 
material to patentability of the subject matter claimed in this application, as "materiality" is defined in 37 C.F.R. § 
1.56. 



I hereby claim foreign priority benefits under 35 U.S.C. § 119(a)-(d) or § 365(b) of any foreign 
application(s) for patent or inventor's certificate hsted below, or under § 365(a) of any PCT international application 
listed below designating least one country other than the United States of America, and have identified below any 
foreign application for patent or inventor's certificate, or of any PCT intemational application, having a fihng date 
before that of the apphcation on which priority is claimed. 

Prior Foreign Application No. Country Filing Date Priority Cert, copy 

fmm/dd/yy) Claimed Attached 

N/A 



I hereby claim the benefit under 35 U.S.C. § 119(e) of any United States provisional application(s) hsted 

below. 

Provisional Application No. Filing Date 

(mm/dd/yy) 

60/158,940 10/12/99 



I hereby claim the benefit under 35 U.S.C. § 120 of any United States apphcation(s) listed below^ or under 
§ 365(c) of any PCT intemational application listed below designating the United States of America, and, insofar as 
the subject matter of each of the claims of this application is not disclosed in the prior United States or PCT 
intemational application in the manner provided by the first paragraph of 35 U.S.C. § 1 12, 1 acknowledge the duty to 
disclose all information known to me to be material to the patentability of the subject matter claimed in this 
apphcation, as "materiality" is defined in 37 C.F.R. § 1.56, which became available between the filing date of the 
prior application and the national or PCT intemational filing date of this application. 

Parent Application No. Filing Date Parent Patent No. (if applicable) or Status 

(mm/dd/yy) 

N/A 
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Please direct all communications to: 

Jeffrey C. Hood 
Conley, Rose & Tayon, P.C. 

P.O. Box 398 
Austin, Texas 78767-0398 
Phone: (512)476-1400 

I hereby declare that all statements made herein of my own knowledge are true and that all statements made 
herem on information and belief are beheved to be true; and further that these statements were made with the 
knowledge that willful false statements and the like so made are punishable by fme or imprisonment, or both, under 
18 U.S.C. § 1001 and that such willful false statements may jeopardize the validity of the apphcation or any patent 
issued thereon. 



Inventor's Full Name: Rajeev Chawla 

Inventor's Signature: ^^Mf^^^tj^^ Date: Dlji%jZ0O0 

City and State (or Foreign Country) of Residence: OvUdT) Ci t^ ^ Cf\ Citizenship: foA^XjUi 
Post Office and Residence Address: 

(Include number, street name, city, state and zip code) 



Inventor's Full Name: Fel Bautista 

Inventor's Signature: 



^^^2^^ Date: I n fz4>00 

City and State (or Foreign Country) of Residence: If-e^ Citizenship: 6tS 



Post Office and Residence Address : /?) ^MhA'^P^ ^Ikn/"^^. P^^wH^i ^ ^4^4 

(Include number, street name, city, state and zip code; 



Inventor's Full Name: Marco Framba 



Inventor's Signature: 

^^.^..^^^^^ Date: ^lld]zoO0 

City and State (or Foreign Country) of Residence: CUPe, fZTi^Of Citizenship: 1 TACj/^AJ 

Post Office and Residence Address: ^^^^B/J AVl£ ^ Cu PtB^T j A/o ^ CR *^Soi^ 

(Include number, street name, city, state and zip code) 
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Inventor's Full Name: Venky Talla 

Inventor's Signature: ^^(m^^^ Date: (8 ( CO 

City and State (or Foreign Country) of Residence: F IL€ ^O^T , CA Citizenship: j a/J) ( f^r^ 

Post Office and Residence Address: Up^g^gfJ Qy,^ p/^gKO/JT^ CAr 'M^^ ^y 

(Include number, street name, city, state and zip code) 



Inventor's Full Name: Rajd eep Gupta 

Inventor's Signature: >|^^Jygg^ .^S^<Ap::4>. Date: Ql/jg/zOOO 

City and State (or Foreign Country) of Residence: / ^\ nV f\^Cij CA Citizenship: (J <^J^ 

Post Office and Residence Address: \^ T^ppPrtDTw Ot. IflV^grU^ CA ^fSQ l. 

(Include nufil)er, street hame, city/state and zip code) 
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